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Description 



[METHOD FOR IDENTIFYING PRODUCT 
ASSETS IN A SUPPLY CHAIN USED TO 
SATISFY MULTIPLE CUSTOMER 
DEMANDS] 

Cross Reference to Related Applications 

[0001] The present application is related to pending U.S. Patent 
Application 10/707,978, filed on 01/29/2004, to Denton 
et al., entitled "A METHOD FOR SUPPLY CHAIN COMPRES- 
SION" having (IBM) Docket No. BUR920030197US1; U.S. 
Patent Application 10/707,974, filed on 01/29/2004, to 
Denton et al., entitled "METHOD FOR PURCHASE ORDER 
RESCHEDULING IN A LINEAR PROGRAM" having (IBM) 
Docket No. BUR92004009US1; U.S. Patent Application 
10/707,976, filed on 01/29/2004, to Denton et al., enti- 
tled "A METHOD FOR OPTIMIZING FOUNDRY CAPACITY" 
having (IBM) Docket No. BUR920030195US1; U.S. Patent 
Application 10/707,972, filed on 01/29/2004, to Denton 



et al., entitled "METHOD FOR FAIR SHARING LIMITED RE- 
SOURCES BETWEEN MULTIPLE CUSTOMERS" having (IBM) 
Docket No. BUR920040010US1; U.S. Patent Application 
10/707,979, filed on 01/29/2004, to Denton et al., enti- 
tled "A METHOD FOR CONSIDERING HIERARCHICAL PRE- 
EMPTIVE DEMAND PRIORITIES IN A SUPPLY CHAIN OPTI- 
MIZATION MODEL" having (IBM) Docket No. 
BUR920030198US1; U.S. Patent Application 10/707,973, 
filed on 01/29/2004, to Denton et al., entitled " METHOD 
FOR SIMULTANEOUSLY CONSIDERING CUSTOMER COMMIT 
DATES AND CUSTOMER REQUEST DATES" having (IBM) 
Docket No. BUR920040008US1; and U.S. Patent Applica- 
tion 10/707,977, filed on 01/29/2004, to Denton et al., 
entitled "A METHOD FOR SUPPLY CHAIN DECOMPOSITION" 
having (IBM) Docket No. BUR920040007US1. The forego- 
ing applications are assigned to the present assignee, and 
are all incorporated herein by reference. 
Background of Invention 

[0002] FIELD OF THE INVENTION 

[0003] The present invention relates to the field of decision sup- 
port methods and systems for identifying production as- 
sets in complex multi-stage and multi-plant manufactur- 



ing system environments in order to track assets needed 
to fulfill multiple customer demands. 
[0004] BACKGROUND OF THE INVENTION 

[0005] | n modern complex multi-stage and multi-plant manufac- 
turing production facilities such as those used in the 
semiconductor industry, assignment and tracking of pro- 
duction assets in a supply chain to meet multiple cus- 
tomer demands is not a trivial undertaking and current 
solutions have serious drawbacks. 

[0006] | n a fj rs t example, user inputted rules project asset pro- 
duction using the bill of material (BOM) and inter-plant 
transfers allowing projection to the final stocking point 
and then matching the projection to demand. However, 
accuracy of the system is entirely dependent upon the ac- 
curacy of the rules used and often results in mis-matches 
between projection and actual results. 

[0007] ^ a second example, final customer information is em- 
bedded within the production-scheduling tools allowing 
planning and tracking through the BOM cycle. However, in 
very large enterprises a severe degradation in the perfor- 
mance of the production-scheduling tool results and it is 
difficult to implement this method when many different 
types of sub-production planning tools are scattered 



throughout the supply chain. 
[0008] Therefore, there is a need for a method and system for 

generating relationships between supply chain assets in a 
complex multi-stage, multi-part number, and multi-plant 
manufacturing environment and multiple customer de- 
mands such that the generated relationships are consis- 
tent with planned production schedules for the manufac- 
turing environment. 
Summary of Invention 

[0009] a first aspect of the present invention is a method for 

identifying product assets in a supply chain used to satisfy 
customer demands, comprising: receiving a feasible 
schedule of all components to be assembled into prod- 
ucts; receiving customer schedules for delivery of the 
products; and generating from the feasible schedule, from 
the customer schedules and from bills of materials listing 
all components required for a particular product, a set of 
demand pegging records, the demand pegging records 
associating a quantity and an availability date of each 
component of each product with a required quantity of 
each of the products, each demand pegging record con- 
sistent with the feasible schedule. 

[0010] a second aspect of the present invention is a method for 



identifying product assets in a supply chain used to satisfy 
customer demands, comprising: (a) mapping a planned 
inventory requisition file comprising component availabil- 
ity schedules and a customer demand file comprising 
product shipment schedules for products assembled from 
components into a requisition map file associating the 
component availability schedules and the product ship- 
ment schedules and including quantities of each compo- 
nent to be used for each product, each component and 
product having a low-level-code indicating a sequence in 
which the components are assembled into the products 
and each product and component having a unique part- 
number; (b) selecting all records from the requisition map 
file of components or products having low-level codes 
equal to a current low-level-code; (c) selecting, from a 
planned asset file comprising component schedules, 
records having part numbers equal to the part numbers in 
the records selected in step (b); (d) selecting, from the 
planned inventory requisition file, records having part 
numbers equal to the part numbers in the records se- 
lected in step (b); (e) mapping records selected in steps (c) 
and (d) into a coverage file associating component avail- 
ability with component requirements for each product; (f) 



mapping the coverage file and records of corresponding 
part numbers from the requisition map file into a demand 
pegging output file comprising demand pegging output 
records, the demand pegging records associating a quan- 
tity and an availability date of each component required to 
produce a required quantity of each of the products, each 
demand pegging record consistent with the feasible 
schedule; (g) generating additional records in the requisi- 
tion map file for components required to fabricate prod- 
ucts whose records were mapped into said demand peg- 
ging output file in step (f); and (h) incrementing the cur- 
rent low-level-code and repeating steps (b) through (h) 
until the current low-level code is higher than a highest 
low-level-code of any component or product. 
[001 1] a third aspect of the present invention is a computer sys- 
tem comprising a processor, an address/data bus coupled 
to the processor, and a computer-readable memory unit 
adapted to be coupled to the processor, the memory unit 
containing instructions that when executed by the proces- 
sor implement a method for identifying product assets in 
a supply chain used to satisfy customer demands, the 
method comprising the computer implemented steps of: 
receiving a feasible schedule of all components to be as- 



sembled into products; receiving customer schedules for 
delivery of the products; and generating from the feasible 
schedule, from the customer schedules and from bills of 
materials listing all components required for a particular 
product, a set of demand pegging records, the demand 
pegging records associating a quantity and an availability 
date of each component of each product with a required 
quantity of each of the products, each demand pegging 
record consistent with the feasible schedule. 
[0012] a fourth aspect of the present invention is a computer 

system comprising a processor, an address/data bus cou- 
pled to the processor, and a computer-readable memory 
unit adapted to be coupled to the processor, the memory 
unit containing instructions that when executed by the 
processor implement a method for identifying product as- 
sets in a supply chain used to satisfy customer demands, 
the method comprising the computer implemented steps 
of: (a) mapping a planned inventory requisition file com- 
prising component availability schedules and a customer 
demand file comprising product shipment schedules for 
products assembled from components into a requisition 
map file associating the component availability schedules 
and the product shipment schedules and including quan- 



tities of each component to be used for each product, 
each component and product having a low-level-code in- 
dicating a sequence in which the components are assem- 
bled into the products and each product and component 
having a unique part-number; (b) selecting all records 
from the requisition map file of components or products 
having low-level codes equal to a current low-level-code; 
(c) selecting, from a planned asset file comprising compo- 
nent schedules, records having part numbers equal to the 
part numbers in the records selected in step (b); (d) se- 
lecting, from the planned inventory requisition file, 
records having part numbers equal to the part numbers in 
the records selected in step (b); (e) mapping records se- 
lected in steps (c) and (d) into a coverage file associating 
component availability with component requirements for 
each product; (f) mapping the coverage file and records of 
corresponding part numbers from the requisition map file 
into a demand pegging output file comprising demand 
pegging output records, the demand pegging records as- 
sociating a quantity and an availability date of each com- 
ponent required to produce a required quantity of each of 
the products, each demand pegging record consistent 
with the feasible schedule; (g) generating additional 



records in said requisition map file for components re- 
quired to fabricate products whose records were mapped 
into the demand pegging output file in step (f); and (h) in- 
crementing the current low-level-code and repeating 
steps (b) through (h) until the current low-level code is 
higher than a highest low-level-code of any component or 
product. 

[0013] a fifth aspect of the present invention is a program stor- 
age device readable by machine, tangibly embodying a 
program of instructions executable by the machine to 
perform method steps for identifying product assets in a 
supply chain used to satisfy customer demands the 
method steps comprising: receiving a feasible schedule of 
all components to be assembled into products; receiving 
customer schedules for delivery of the products; and gen- 
erating from the feasible schedule, from the customer 
schedules and from bills of materials listing all compo- 
nents required for a particular product, a set of demand 
pegging records, the demand pegging records associating 
a quantity and an availability date of each component of 
each product with a required quantity of each of the prod- 
ucts, each demand pegging record consistent with the 
feasible schedule. 



[0014] a sixth aspect of the present invention is a program stor- 
age device readable by machine, tangibly embodying a 
program of instructions executable by the machine to 
perform method steps for identifying product assets in a 
supply chain used to satisfy customer demands the 
method steps comprising: (a) mapping a planned inven- 
tory requisition file comprising component availability 
schedules and a customer demand file comprising prod- 
uct shipment schedules for products assembled from 
components into a requisition map file associating the 
component availability schedules and the product ship- 
ment schedules and including quantities of each compo- 
nent to be used for each product, each component and 
product having a low-level-code indicating a sequence in 
which the components are assembled into the products 
and each product and component having a unique part- 
number; (b) selecting all records from the requisition map 
file of components or products having low-level codes 
equal to a current low-level-code; (c) selecting, from a 
planned asset file comprising component schedules, 
records having part numbers equal to the part numbers in 
the records selected in step (b); (d) selecting, from the 
planned inventory requisition file, records having part 



numbers equal to the part numbers in the records se- 
lected in step (b); (e) mapping records selected in steps (c) 
and (d) into a coverage file associating component avail- 
ability with component requirements for each product; (f) 
mapping the coverage file and records of corresponding 
part numbers from the requisition map file into a demand 
pegging output file comprising demand pegging output 
records, the demand pegging records associating a quan- 
tity and an availability date of each component required to 
produce a required quantity of each of the products, each 
demand pegging record consistent with the feasible 
schedule; (g) generating additional records in said requi- 
sition map file for components required to fabricate prod- 
ucts whose records were mapped into the demand peg- 
ging output file in step (f); and (h) incrementing the cur- 
rent low-level-code and repeating steps (b) through (h) 
until the current low-level code is higher than a highest 
low-level-code of any component or product. 
Brief Description of Drawings 

[0015] The features of the invention are set forth in the ap- 
pended claims. The invention itself, however, will be best 
understood by reference to the following detailed descrip- 
tion of an illustrative embodiment when read in conjunc- 



tion with the accompanying drawings, wherein: 
[0016] FIGs. 1A, IB and 1C comprise a single flowchart illustrat- 
ing the major steps of the method of the present inven- 
tion; 

[° 017 ] FIGs. 2 A, 2B and 2C illustrate the concept of low- 
level-codes utilized by the present invention; 

[0018] FIGs. 3A, 3B, 3C, 3D, 3E, 3F, 3G, 3H, 31, 3J and 3K are ex- 
amples of various files used or generated by the present 
invention; 

[0019] FIG. 4 is a flowchart of sub-steps for the pegging with 

binning step of the flowchart of FIG. 1C according to the 

present invention; 
[0020] FIGs. 5A and 5B illustrate demand pegging with binning 

according to the present invention; and 
[0021] FIG. 6 is a schematic block diagram of a general-purpose 

computer for practicing the present invention. 
Detailed Description 

[0022] a planned asset is defined as an asset having a release 
date into manufacturing later than a date that a produc- 
tion-scheduling run was performed. A planned asset is an 
asset that will exist at some time in the future from the 
current time. Demand pegging is defined as associating 
planned or actual assets with particular demands for 



those assets. Assets include all component parts and final 
parts in a supply chain. A schedule is defined as an avail- 
ability or delivery date for a stated quantity of a specified 
asset, component or product herein and in the claims. For 
example, quantities of component part numbers (P/N)s 
required to produce a required quantity of a given P/N for 
shipment to a customer are "reserved" for that purpose. 
Binning is defined as sorting a single asset into two or 
more different assets. For example, one P/N (the binable 
P/N) may be sorted into multiple different P/Ns (binned P/ 
Ns) having different values for one or more different spec- 
ifications applicable to the binable P/N. Often binned P/Ns 
can be substituted for one another. For example a higher 
speed sort part can be substituted for a lower speed sort 
part. A feasible schedule is defined as a schedule for a 
supply chain wherein availability or shipment dates of 
component assets required to produce a final product and 
to support a shipment date of the final product made 
from those component assets are consistent with compo- 
nent ship dates and also with product ship dates. A de- 
mand pegging schedule is consistent with a feasible 
schedule by definition when quantities and dates of cus- 
tomer shipments and those dates and quantities in a pro- 



duction-scheduling run (PSR) are identical and the de- 
mand pegging file reflects the same sources of compo- 
nents as the PSR. Those sources include but are not lim- 
ited to multi-sources, substitution sources and manufac- 
turing release sources. A PSR is a feasible plan. Methods 
and tools for performing PSRs and generating PSR sched- 
ules are well known in the art and are often customized 
for individual production lines. 
[0023] FIGs. 1A, IB and 1C comprise a single flowchart illustrat- 
ing the major steps of the method of the present inven- 
tion. In FIG. 1A, in step 100, low-level-codes (LLC) are 
generated and written to LLC file 105. LLC file 105 is sim- 
ply a listing of the P/Ns of all the production assets of the 
entire supply chain as indicated by the BOM for all prod- 
ucts and customers of a production facility and the LLC 
assigned to each P/N. The production facility may extend 
across multiple production plants and may include ven- 
dors and the P/Ns include components as well as final 
product shippable to a customer. The LLC indicates a se- 
quence in which parts must be processed based on bill of 
material. Groups of parts sharing the same LLC may be 
processed concurrently. The fields of each record and a 
description of those fields of LLC file 105 are described in 



Table I infra. 



TABLE I 



LLC FILE 


Part Number 


A unique product identifier 


Low-level-code 


Low-level-code indicating sequence part numbers should 
be processed by this invention. 



[0024] Turning to FIGs. 2A, 2B and 2C, FIGs. 2 A, 2B and 2C illus- 
trate the concept of LLCs utilized by the present invention. 
In FIG. 2A, P/N C is fabricated using P/N D, P/N B is fabri- 
cated using P/N C and P/N A is fabricated using P/N B. P/ 
N A is customer shippable product. Thus in the supply 
chain ABCD, P/N A is assigned an LLC of 1, P/N B an LLC 
of 2, P/N C an LLC of 3 and P/N D an LLC of 4. When mul- 
tiple P/Ns are required to fabricate the same P/N, then the 
multiple P/Ns are assigned the same LLC. For example, if 
P/N E is also required to fabricate P/N C, then P/N E would 
be assigned the same LLC as P/N D, namely LLC 4. Gener- 
ation of LLCs is well known in the art and generation of 
LLCs for P/Ns having more than one component P/N is 
taught in U.S. Pat. No. 5,943,484 co-assigned to Interna- 
tional Business Machine Corporation, Armonk NY, and is 
hereby incorporated by reference in its entirety. 

[0025] FIG. 2B illustrates LLCs when two different P/Ns in two 

different supply chains utilize the same manufacturing re- 



source. In FIG. 2B, supply chain ABCD is the same as in 
FIG. 2A, but a new supply chain XYZ is introduced. In sup- 
ply chain XYZ, P/N Y is fabricated using P/N Z and P/N X 
is fabricated using P/N Y. P/N X is a customer shippable 
part. P/N X and P/N B share a common manufacturing re- 
source. The LLC generation methods described supra 
would assign an LLC of 1 to X, 2 to Y and 3 to Z, but this 
would result in potential conflicts, therefore P/N X must 
be assigned an LLC of 2, P/N Y an LLC of 3 and P/N Z an 
LLC of 4. FIG. 2C illustrates the case where additionally P/ 
N C and P/N Z share the same manufacturing resource. In 
this case P/N A is assigned an LLC of 1, P/Ns B and X an 
LLC of 2, P/N Y an LLC of 3, P/Ns C and Z an LLC of 4 and 
P/N D an LLC of 5. Generation of LLCs for P/Ns sharing 
manufacturing resource is taught in U.S. Pat. No. 
6,584,370 co-assigned to International Business Machine 
Corporation, Armonk NY, and is hereby incorporated by 
reference in its entirety. 
[0026] The selection of standard LLCs, multiple component LLCs, 
shared manufacturing resource, or LLCs accounting for 
both multiple components and shared resources by dif- 
ferent P/Ns is determined by the user. Likewise, step 100 
of FIG. 1A may be performed externally to the practice of 



the present invention and LLC file 105 supplied. 

[0027] Returning to FIG. 1A, in step 110, the customer shipments 
are associated to customer demands. Step 110 uses infor- 
mation from a planned inventory requisition file 115 gen- 
erated by a PSR and a customer demand file 120 (which 
was used to generate the PSR) to generate a requisition 
map file 125 to establish an association between cus- 
tomer shipments in planned inventory requisition file 115 
and customer demand file 120. As described infra, in each 
LLC loop, requisition map file 125 is updated several 
times. This association may be a many-to-many relation- 
ship as one shipment may cover several demands and 
several shipments may cover one demand. Each of the 
output records of this process will contain information on 
specific customer demands and the particular customer 
shipments that will satisfy the demand from the PSR. 
However, a shortcoming of a PSR schedule is the relation- 
ship between component P/Ns and the final or customer 
P/N made from those component P/Ns is not visible. 

[0028] The fields of each record and a description of those fields 
of planned inventory requisition file 115, customer de- 
mand file 120 and requisition map file 125 are described 
respectively in tables II, III and IV infra and examples files 



are illustrated respectively in FIGs. 3A, 3B and 3C. 



TABLE II 



PLANNED 
INVENTORY 
REQUISITION 
FILE 


Planned requisitions from inventory for a given P/N at a given 
manufacturing plant, which are calculated by the production- 
scheduling run. These requisitions indicate how inventory is 
consumed and for what purpose. 


Part Number 


A unique product identifier 


Plant 


A location descriptor indicating where inventory will be 
consumed 


Requisition Type 


A code indicating the purpose of the requisition. The following 
are key requisition types: 

"CSHP" - a requisition of inventory required to make a shipment 
to a customer. 

"COMP" - a requisition of component inventory required to 
support a planned manufacturing release. There will be a 
matching "PL" entry for the assembly part number with the same 
requisition identifier in planned asset file 145 discussed infra. 
"SUB" - a requisition of inventory to use this given part number 
in place of another part number. There will be a corresponding 
"SUB" entry for the part number for which this part is 
substituting in planned asset file 145 discussed infra. 
"INTSHP" - a requisition to send inventory from this plant to 
another plant. There will be a corresponding "INTRECPT" entry 
for the receiving plant in planned asset file 145 discussed infra. 


Requisition 
Identifier 


A unique code identifying this specific planned inventory 
requisition. 


Planned Asset 
Reference 


For a requisition indicating the part will be used as a substitution 

for another part number, this field will reference the part number 

for which the substitution is being made. 

For a requisition indicating the part will be used as an interplant 

shipment to another plant (not a customer), this field will 

reference the plant the product is being shipped to. 

For a requisition indicating the part will be used as a component 

for an assembly, this field will reference the assembly part 

number. 


Quantity 


The quantity to be removed from inventory. 


Date 


The date on which the requisition of inventory needs to be 
performed. 


Customer Code 


A code identifying the customer requesting the product. 


OTHER 


Other fields per user requirements. 



TABLE III 



CUSTOMER 
DbMAND HLE 

— — — — 


This is a file of customer product shipment schedules. It is 
common to both the method of the present invention and the 
production-scheduling run whose output includes Planned 
Inventory Requisition File 115 which is an input to the present 
invention. 


Part Number 

— — 


A unique product identifier for the product desired by the 
customer 


(customer Code 


A code identifying the customer requesting the product 


Demand Type 


A code identifying the type of demand. For example, a demand 
may be a hard committed order or it may be a forecast 


Request Quantity 


The quantity requested by the customer 


Request Date 


The date for which the customer is requesting the product. 


Order Number 


A unique identifier associated with this particular demand record. 


OTHER 


There may be many data elements associated with a customer 
demand which may be carried through for reporting purposes as 
part of the eventual output of this invention based on user needs 



TABLE IV 



REQUISITION MAP FILE 


A mapping of planned requisitions from planned 
inventory requisition file 1 15 and demands from customer 
demand file 120. 


Part Number 


A unique product identifier (from planned inventory 
requisition file 115). 


Plant 


A location descriptor indicating where inventory will be 
consumed (from planned inventory requisition file 115). 


Requisition Type 


A code indicating the purpose of the requisition (from 
planned inventory requisition file 115). 


Requisition Identifier 


A unique code identifying this specific planned requisition 
(from planned inventory requisition file 115). 


Reference 


Corresponding planned asset reference (from planned 
inventory requisition file 115). 


Requisition Date 


Date inventory for this part number / plant will be 
consumed (from planned inventory requisition file 1 15). 


Consumption Quantity 


Portion of requisition that is being tied to the specific 
customer demand below (calculated). 


Customer Part Number 


The part number associated with the customer order (from 
customer demand file 120). 


Customer Code 


A code identifying the customer requesting the product 
(from planned inventory requisition file 115). 


Order Number 


A unique identifier associated with this particular demand 
record (from customer demand file 120). 


Customer Demand Quantity 


Portion of the customer demand quantity covered by the 
Requisition Type and Identifier (calculated). 


OTHER 


Other fields per user requirements. 



[0029] Requisition map file 125 is generated as follows:(l) from 



planned inventory requisition file 115, for all Requisition 
Type fields = "CSHP" copy fields Part Number, Plant, Req- 
uisition Type, Requisition Identifier, Date and Customer 
Code into corresponding fields of records in requisition 
map file 125;(2) from customer demand file 120 find all 
records having Part Number and Customer Code corre- 
sponding to those in (1) and copy fields Customer Part 
Number and Order Number into corresponding fields of 
records in requisition map file 125;(3) calculate the Con- 
sumption Quantity field by disaggregating the Quantity 
field of planned inventory requisition file 115 against all 
demands for each P/N; and(4) calculate the Customer De- 
mand Quantity field by disaggregating the Request Quan- 
tity field of customer demand file 120. 
[0030] For example, the Quantity field of the first record of the 
Example Planned Inventory Requisition File of FIG. 3A is 
100 (of PN1) and disaggregates into the first record Con- 
sumption Quantity of 50 (of PN1) and the second record 
Consumption Quantity of 50 (of PN1) of the Example Req- 
uisition Map File of FIG. 3C. The Quantity field of the third 
record of the Example Planned Inventory Requisition File 
of FIG. 3A is 300 (of PN1) and disaggregates into the third 
record Consumption Quantity of 300 (of PN1) of the Ex- 



ample Requisition Map File of FIG. 3C. There are various 
methods for disaggregating known to those of ordinary 
skill in the art. Step 110 essentially initializes requisition 
map file 125 for the first pass through the LLC loop as 
described infra. 

[0031] Returning to FIG. 1A, in step 130 the first time though, 
the lowest numerical, for example 1, LLC is chosen. In 
subsequent iterations the next higher (numerically) LLC is 
chosen, for example 2 or higher. If all LLCs have been 
chosen the method is complete and processing termi- 
nates. In step 135, a list of all P/Ns that exist in records in 
the current version of requisition map file 125 assigned to 
the current LLC are selected and held in memory or in a 
temporary file. Then, in step 140, records from a planned 
asset file 145 having P/Ns and Plants the same as the P/ 
Ns and Plants that exist in the records selected from the 
current version of requisition map file 125 are selected. 
Planned asset file 145 is generated from the PSR de- 
scribed supra. The fields of each record and a description 
of those fields of planned asset file 145 is described in ta- 
ble V infra and an example file is illustrated in FIG. 3D. 



TABLE V 



PLANNED ASSET 
FILE 


These are either actual production assets such as inventory and 
work-in-process for a given part number or future planned assets 
which will be created as recommended by the production- 
scheduling run by either through receipt of products from other 
plants or from releasing new work-in-process into the 
manufacturing line. 


Part Number 


A unique product identifier. 


Plant 


A location descriptor indicating where inventory will be created. 


Asset Type 


A code indicating the form of the present or planned asset. The 
following are our key asset types: 
"INV" - current available inventory. 

"WIP" - work-in-process in the manufacturing line for the given 
part number and plant which is projected to become inventory at a 
future date. 

"PL" - a planned manufacturing release. This is a planned release 
of material into the manufacturing line at a future date, which will 
become "WIP." If this planned release requires component parts, 
there will be corresponding entries for the component parts as 
"COMP" entries in planned inventory requisition file 115. 
"SUB" - a planned receipt of a part number, which can be used in 
place of the part number associated with this asset. The part 
number that is being used to substitute for the part number on this 
asset will have a corresponding "SUB" entry in the planned 
inventory requisition file described above. 
"INTRECPT" - a planned receipt of the part number from 
another location. There will be a corresponding "INTSHP" entry 
on the sending plant in planned inventory requisition file 115. 


Asset Identifier 


A unique identifier identifying this particular actual or planned 
asset. 


Planned Inventory 

Requisition 

Reference 


For an Asset Type representing that another part number will be 
used to substitute for the given part number, this field will 
reference the part number that is being used for the substitution. 
For an Asset Type representing a receipt of the part number from 
another plant, this field will indicate the plant that is shipping the 
part. 


Projected Quantity 


Quantity that is projected to be placed in inventory corresponding 
to this asset. 


Projected Date 


Date on which the asset is planned to be available in inventory 
(I.e.. consumable bv a planned inventory requisition). 


Start Quantity 


For a "PL" Asset Type (i.e., planned manufacturing release), the 
quantity of product that is planned for introduction into 
manufacturing. This differs from Projected Quantity as yield loss 
may occur during processing. 


Start Date 


For a "PL" Asset Type, the date the product is planned for 
introduction into manufacturing. This differs from the Projected 
Date as lead-time is normally needed to make a product. 


OTHER 


Other fields per user requirements. 



[0032] Next, in step 150, records from planned inventory requi- 



sition file 115 having P/Ns and Plants the same as the P/ 
Ns and Plants in the records selected from the current 
version of requisition map file 125 are selected. 
[0033] | n s tep 155, the records selected from planned asset file 
145 in step 140 and the records selected from planned 
inventory requisition file 115 in step 150 are mapped into 
a coverage 1 file 160A or a coverage 2 file 160B. The 
fields of each record and a description of those fields of 
coverage 1 file 160A and coverage 2 file 160B are de- 
scribed in table VI infra and an example file is illustrated 
in FIG. 3E. 



TABLE VI 



COVERAGE 1 
AND 

CUV JbKAAjrJb z 

FILES 


A mapping of associating planned assets (from planned asset file 
145) with planned inventory requisitions (from planned inventory 
requisition file 1 15). These consist of two intermediate files with 
the same data elements. The file called coverage 1 associates 
planned assets with planned inventory requisitions of type 
"CSHP" (customer shipment) and "COMP" (component for a 
subsequent assembly- 5 ). Coverage 2 associates planned assets 
with planned inventory requisitions of all other types. 


Part Number 


A unique product identifier (from planned inventory requisition 
file 1 15 or from planned asset file 145). 


Plant 


A location descriptor indicating where inventory will be 
consumed (from planned inventory requisition file 1 1 5 or from 
planned asset file 145). 


Asset Type 


Type of asset being consumed by the specific planned inventory 
requisition (from planned asset file 145). 


A QCf^t TH<=*rvf"i"fi/=»r 
^T-abCL lUCllLlllCl 


A unique code identifying this specific planned asset (from 
planned asset file 145). 


riaiiiicu iiivciiLury 

Requisition 


References corresponding planned asset records for interplant 
shipment and substitution asset types (from planned inventory 
requisition file 1 15 Planned Asset Reference field and from 
planned asset file 145 Planned Requisition Reference). 


Requisition Type 


Type of requisition that is consuming the asset (from planned 
inventory requisition file 115). 


Requisition 
Identifier 


A unique code identifying this specific planned inventory 
requisition (from planned inventory requisition file 115). 


Quantity 


Quantity of asset, which will be consumed for this specific 
requisition (calculated from field Projected Quantity of planned 
asset file 145). 


Asset Availability 
Date 


Date when the asset was available for consumption (might have 
been earlier than when it is planned for consumption; from 
Projected Date field of planned asset file 145). 


Requisition Date 


Date when asset will be consumed by this specific requisition 
(from planned inventory requisition file 115). 


Start Date 


If Asset Type is planned manufacturing release ("PL"), this field 
reflects the start date for the release (from planned asset file 145). 


Start Quantity 


For a PL Asset Type (i.e., planned manufacturing release), the 
quantity of product that is planned for introduction into 
manufacturing corresponding to the Quantity field above. This 
differs from Quantity reflecting yield loss, which occurs during 
manufacturing processing. 


OTHER 


Other fields per user requirements. 



[0034] The difference between coverage 1 file 160A and coverage 
2 file 160B is coverage 1 file is based on Requisition Type 
field "CSHP" or "COMP" records while coverage 2 file in- 



eludes all other Requisition Type field records. Alterna- 
tively, coverage 1 file 160A and coverage 2 file 160B may 
be a single file with an indicator field or steps that use 
coverage 1 file 160A or coverage 2 file 160B may read the 
Requisition Type field to determine what methodology or 
process to apply. 

[0035] Coverage 1 file 160A and coverage 2 file 160B are gener- 
ated as follows:(l) from records selected from planned 
asset file 145, copy fields Part Number, Plant, Asset Type, 
Asset Identifier and Planned Inventory Requisition Refer- 
ence, into corresponding fields of appropriate coverage 1 
file 160A or coverage 2 file 160B as described supra;(2) 
from records selected from planned inventory requisition 
file 115 copy fields Requisition Type and Requisition Iden- 
tifier into corresponding fields of appropriate coverage 1 
file 160A or coverage 2 file 160B as described supra; 
and(3) calculate the Quantity field by disaggregating the 
Projected Quantity field of planned asset file 145 and the 
Quantity field of planned inventory requisition file 115 
(see FIG. 3A, 3D and 3E for examples). 

[0036] | n s tep 165, all records in requisition map file 125 whose 
part numbers correspond to the current LLC are selected 
and either held in memory, held in a temporary file or a 



pointer file generated for locating these selected records 
in the current version of requisition map file 125. The 
method now proceeds through connector "A"to step 170 
of FIG. IB. 

[0037] Turning to FIG. IB, in step 170, the records of coverage 1 
file 160Aand requisition map file 125 (through any of the 
methods described in step 165 supra) are mapped into a 
demand pegging output file 175. Demand pegging output 
file 175 is the final result of the method of the present in- 
vention, but is not complete until all LLC loops as de- 
scribed infra are completed. This is a process that disag- 
gregates so that planned asset quantities covering specific 
portions of customer demands are calculated and out- 
putted to the demand pegging output file 175. Note that 
the processing done in step 110 supra and in steps 215 
and 230 infra guarantees that there will be requisition 
map information for requisition types customer shipments 
(coming from step 110) and components for assemblies 
(coming from steps 215 and 230). Therefore, by quantity, 
the total quantities for each requisition identifier in cover- 
agel file 160A must necessarily match the total quantities 
in requisition map file 125. 

[0038] The fields of each record and a description of those fields 



of demand pegging output file 175 are described in table 
VII infra and an example file is illustrated in FIG. 3F. 



TABLE VII 



DFMAND 

xJ i— '1*1/ \1 > J_y 

PEGGING 
OUTPUT FILE 


rue which cibbucidics ciciiiciiLs 01 me pionneu asset me mo witn 
planned inventory requisition data elements from planned inventory 

rfVllll^itirvn flip 1 1 S finrl with Piietrvmpr H^manH rprwrrlc -frr\m 

iv^uidiuvjii 111c i u aiiu wiLii L-uoiuiiicr uciiiaiiu rcLortia lrom 

customer demand file 120 via coverage 1 file 160A and coverage 2 
file 160B. The net result is that planned assets are associated with 
vudiuiixci uciiiaiiua iiu iiiaLLci vviicic in me >uppiy cflain tne assets 
reside. 


Part Number 


A unique product identifier (from coverage 1 file 160A or coverage 
2filel60B) 


Plant 


A loc&tion descriptor indicating where inventory will be crested 
(originally from planned asset file 145) 


Asset Type 


.rt. tuuc iiiuicaimg uic luiiii ui liic present or pianixcu assex 
(originally from planned asset file 145). 


Asset Availability 
Date 


Date when the asset was available for consumption (might have 
uggu ccuiici man whcii ii ib piaimeu lor consumption^ ^originally 
from planned asset file 145) 


Start Date 


If Asset Type is a planned manufacturing release ("PL"), this field 
iciic^ia uic Man udie iui uic release, mis umers irom tne Asset 
Availability Date as lead-time is normally needed to make a 

nrnnilPt /VvnO'l'nPill v from nl q n n p»H occpf fi1i=» 
jJiV-JviUA^i. ^wii^iiia.ll_y 1IU11I piallllCU. aaaCl 111C l*tj / 


Asset Identifier 


A unique code identifying this particular actual or planned asset 
(originally from planned asset file 145) 


jvc^uiMiiuii i ypc 


Type of requisition that is consuming the asset (originally from 
planned inventory requisition file 115) for the specific end customer 
demand 


Requisition 
Identifier 


A unique code identifying this specific inventory requisition that is 
consuming the asset (originally from planned inventory requisition 
file 1 15) for the specific end customer demand below. 


Quantity 


viuauui) ui abaci, wiii^n win dc consumcu ior tnis specinc 
inventory requisition for this specific end demand. (Calculated) 


Start Onantitv 


Quantity to release into manufacturing corresponding to the 
Quantity field if this is for an Asset Type representing a 
manufacturing release. (Calculated) 


Customer Part 
Number 


The part number being ordered or forecast by the customer, 
(originally from customer demand file 120) 


Customer Code 


A code identifying the customer requesting the product (originally 
from customer demand file 120). 


Order Number 


A unique identifier associated with this particular demand record 
(originally from customer demand file 120). 


Customer Demand 
Quantity 


Portion of the customer demand quantity covered by this record. 
(Calculated) 


OTHER 


Other fields per user requirements. 



[0039] Records for demand pegging file 175 from coverage 1 file 



160A are generated as follows:(l) copy fields as indicated 
in TABLE VII into a new demand pegging output file 175 
record(s);(2) calculate the Quantity field of the new de- 
mand pegging output file 175 record(s) by disaggregating 
the corresponding Quantity field of coverage 1 file 160A 
against all demands for each P/N; (3) calculate the Start 
Quantity field by disaggregating corresponding Start 
Quantity field of coverage 1 file 160A against all demands 
for each P/N; and(4) calculate the Customer Demand 
Quantity field by disaggregating corresponding Customer 
Demand Quantity field of requisition map file 125. 

[0040] For example, the Quantity field of the first record of the 
Example Coverage 1 File 160A and Coverage 2 File 160B 
of FIG. 3E is 100 (of PN1) and shows up disaggregated in 
the Quantity field of the first and second records of the 
Example Demand Pegging Output File of FIG. 3F (50 each). 

[0041] Returning to FIG. IB, in step 180 a process similar to that 
performed in step 170 is performed except planned as- 
sets in coverage 2 file 160B are mapped against customer 
demands in requisition map file 125. Note that step 180 is 
required only when the Asset Type field of records for de- 
mand pegging output file 175 generated in step 170 is 
"SUB"or "INTRECPT." As the requisition map file 125 does 



not have entries for inventory requisitions to satisfy asset 
types of substitutions ("SUB") and interplant shipments 
("INTRECPT"), additional processing beyond simple match- 
ing is required to associate planned assets in coverage 2 
file 160B with customer demands in requisition map file 
125. This is accomplished as follows. Requisitions in cov- 
erage 2 file 160B for interplant shipments and substitu- 
tions must have corresponding planned assets in coverage 
1 file 160A. Therefore, a mapping process is performed to 
find the records in coverage 2 file 160B corresponding to 
"SUB"and "INTRECPT" records in coverage 1 file 160A. This 
would associate planned assets in coverage 2 file 160B 
with customer demands in requisition map file 125 and 
generate new demand pegging records. If the associated 
planned assets are not of Asset Type "INV,""WIP"or "PL", a 
similar process will be performed to locate new records in 
coverage 2 file 160B that have corresponding inventory 
requisitions. This looping process is repeated until the 
Asset Type is either "INV,""WIP"or "INTRECPT". 
[0042] N ext j n step is5 j a decision is made based on the Asset 
Type field of each record in demand pegging output file 
175. For records with asset type "PL"the method proceeds 
to step 195 of FIG. 1C via connector "B"; for all other asset 



types in step 190 no further processing of records is re- 
quired. 

[0043] Turning to FIG. 1C, in step 195 records in demand peg- 
ging output file 175 are filtered so only records for Asset 
Type = "PL" are selected. Then in step 200, a union of the 
records selected in step 195 and corresponding records in 
a bill of material file (BOM) 205 are created and stored in a 
temporary file 2 10. The fields of each record and a de- 
scription of those fields of bill of material file 205 are de- 
scribed in table VIII infra. Examples of temporary file 210 
and of bill of material file 205 are illustrated in FIG.s 31 
and 3G, respectively. 



TABLE VIII 



BILL OF 

MATERIAL FILE 


A bill of material provides a list of component parts and 
quantities necessary to build a P/N which represents an assembly 
of the components. 


Part Number 


A unique product identifier. 


Plant 


The location at which the Part Number above will be built. 


Process 


The particular process that will be used to build the Part Number 
at the above plant. 


Component Part 
Number 


A required component P/N. 


Component Quantity 


A quantity indicating the number of this component required for 
each assembly part being built. 


Binning Flag 


Indicates whether the above Part Number results from a binning 
process. 


OTHER 


Other fields per user requirements. 



[0044] Records in temporary file 210 are generated as follows:(l) 
for each P/N in records filtered from demand pegging 
output file 175;(2) find same P/N in bill of material file 



205; and(3) add Component Part Number, Component 
Quantity and Binning Flag fields from bill of material file 
205 to filtered demand pegging records and write as 
record to temporary file 2 10; if a P/N has multiple com- 
ponent P/Ns, write a record for each component P/N. 

[0045] For example, filtering on the Example Demand Pegging 
Output File of FIG. 3F would select the last three records 
(those with Asset Type = "PL"). The Component P/N, BOM 
Quantity and BIN Flag fields from P/Ns PN3, PN6 and PN7 
in Example Bill Of Material File of FIG. 3G are then added 
to the three selected demand pegging records to generate 
the Example Temporary File of FIG. 31. Because the PN3 
record in FIG. 3G had two component P/Ns (PN4 and PN5), 
there are two PN3 records in FIG. 31. 

[0046] Returning to FIG. 1C, in step 215 new requisition map file 
125 records are created for each record in temporary file 
210 as follows:(l) for each record in temporary file 210 
copy the following fields to the corresponding fields in 
requisition map file 125 to create a new record in requisi- 
tion map file 125: Component P/N to Part Number, Asset 
Identifier to Requisition Identifier, Part Number to Refer- 
ence and Start Date to Requisition Date (other fields map 
with the same field name in both files); and(2) calculate 



the Consumption Quantity field of the new requisition 
map file 125 record by multiplying the Start Quantity field 
of temporary file 210 by the BOM Quantity field of tempo- 
rary file 210. 

[0047] For example, turning to FIG. 3J, the last four records of 
the Example Requisition Map File (After Step 215) were 
generated from the four records of the Example Tempo- 
rary File of FIG. 31. The records are in the same order in 
both files. 

[0048] Returning to FIG. 1C, in step 225, for each record added 
to requisition map file 125 in step 215, the value of the 
BIN Flag field is determined. If the BIN Flag = "N", no fur- 
ther processing is required. However, if the BIN Flag = "Y", 
then in step 230, additional records are added to requisi- 
tion map file 125 to account for any "unused" portion of 
the binned P/N(s). Step 230 is more fully illustrated in FIG. 
4 and described infra. 

[0049] while steps 200 and 215 have been described using tem- 
porary file 210, the invention may be practiced without 
using a temporary file. This is done by gathering the in- 
formation indicated and operating on it directly to pro- 
duce new records or adjust existing records in requisition 
map file 125. 



[0050] After steps 225 and 230 are completed the method re- 
turns to step 130 of FIG. 1A via connector "C."FIG. 4 is a 
flowchart of sub-steps of step 230 of FIG. 1C. In step 235, 
from temporary file 210, the first/next binable P/N (i.e., 
component P/N) is selected and the Start Date field is de- 
termined. In step 240, again from temporary file 210, all 
the records that have the same binable P/N and Start Date 
are selected and each Start Quantity is determined. For 
example, in FIG. 31, the last two records in which Compo- 
nent P/N = "PN8"and Start Date = ,, 3/l/2004"are selected 
and the Start Quantity of PN6 = 50 and of PN7 = 30. 

[0051] | n s tep 245, the (minimum) quantity required by the bin- 
able P/N in order to make all the starts is determined. 
This is accomplished by taking the maximum of each Start 
Quantity divided by the Binning Percentage for each 
binned P/N from binning file 220. Continuing the example 
of FIG. 31, from FIG. 3H it can be found that PN6 has a 
binning percentage of 70% of PN8 and PN7 has a binning 
percentage of 30% of PN8. Therefore the maximum of 
50/. 7 and 30/. 3 is determined, which is 100. Thus 100 
parts of PN8 must be started which will give 70 pieces of 
PN6 and 30 pieces of PN7. 

[0052] | n step 250, it is checked if any binned quantity exceeds 



the amount needed for the customer order. Continuing 
the example of FIG. 31, for PN8/PN6 only 50 are needed 
but 70 are available, so there is an excess of 20 pieces. 
For PN8/PN7 30 parts are needed and 30 are available. 
Note, the case of there not being enough parts to satisfy 
the start for a binned part is not possible because the PSR 
generated a feasible plan, that is, a plan that supplied 
sufficient parts on given dates as reflected in planned in- 
ventory requisition file 115 described supra. 

[0053] | n s tep 255, if a binned quantity of a P/N exceeds that re- 
quired, then in step 260 an additional record is created 
and added to requisition map file 125; otherwise in step 
265 the method loops to step 235 or is done. In step 260 
a record for the excess quantity is created. This may be 
seen in the last record of the Example Requisition Map File 
of FIG. 3K. The last record is identical to the third record 
from the bottom except for the Consumption Quantity 
and Customer Code fields. 

[0054] piGs. 5A and 5B illustrate pegging with binning according 
to the present invention and are self explanatory, describ- 
ing pegging with binning a slightly different way. FIG. 5A 
indicates inputs and outputs required and FIG. 5B de- 
scribes the method. 



[0055] Generally, the method described herein with respect to 
identifying production assets in a supply chain to satisfy 
multiple customer demands is practiced with a general- 
purpose computer and the method may be coded as a set 
of instructions on removable or hard media for use by the 
general-purpose computer. FIG. 6 is a schematic block di- 
agram of a general-purpose computer for practicing the 
present invention. In FIG. 6, computer system 300 has at 
least one microprocessor or central processing unit (CPU) 
305. CPU 305 is interconnected via a system bus 310 to a 
random access memory (RAM) 315, a read-only memory 
(ROM) 320, an input/output (I/O) adapter 325 for a con- 
necting a removable data and/or program storage device 
330 and a mass data and/or program storage device 335, 
a user interface adapter 340 for connecting a keyboard 
345 and a mouse 350, a port adapter 355 for connecting 
a data port 360 and a display adapter 365 for connecting 
a display device 370. 

[0056] ROM 320 contains the basic operating system for com- 
puter system 300. The operating system may alternatively 
reside in RAM 315 or elsewhere as is known in the art. Ex- 
amples of removable data and/or program storage device 
330 include magnetic media such as floppy drives and 



tape drives and optical media such as CD ROM drives. Ex- 
amples of mass data and/or program storage device 335 
include hard disk drives and non-volatile memory such as 
flash memory. In addition to keyboard 345 and mouse 
350, other user input devices such as trackballs, writing 
tablets, pressure pads, microphones, light pens and posi- 
tion-sensing screen displays may be connected to user 
interface 340. Examples of display devices include cath- 
ode-ray tubes (CRT) and liquid crystal displays (LCD). 

[0057] a computer program with an appropriate application in- 
terface may be created by one of skill in the art and stored 
on the system or a data and/or program storage device to 
simplify the practicing of this invention. In operation, in- 
formation for or the computer program created to run the 
present invention is loaded on the appropriate removable 
data and/or program storage device 330, fed through 
data port 360 or typed in using keyboard 345. 

[0058] Thus, the present invention provides a method and sys- 
tem for generating relationships between supply chain as- 
sets in a complex multi-stage, multi-part number, and 
multi-plant manufacturing environment and multiple cus- 
tomer demands such that the generated relationships are 
consistent with planned production schedules for the 



manufacturing environment. 
[0059] The description of the embodiments of the present inven- 
tion is given above for the understanding of the present 
invention. It will be understood that the invention is not 
limited to the particular embodiments described herein, 
but is capable of various modifications, rearrangements 
and substitutions as will now become apparent to those 
skilled in the art without departing from the scope of the 
invention. For example, the method and system described 
herein are not limited to any particular type of product, 
such as semiconductors, but may be used in for tracking 
component assets of any complex product in any complex 
manufacturing environment. A complex manufacturing 
environment defined as an environment fulfilling at least 
one of the following criteria: multiple P/Ns, multiple com- 
ponents for each P/N, multiple levels or steps of fabrica- 
tion, multiple plants or venders, multiple customers, al- 
lowing substitution of assets or allowing interplant ship- 
ment of assets. Therefore, it is intended that the following 
claims cover all such modifications and changes as fall 
within the true spirit and scope of the invention. 



